@louwers can you rerun the GCC14? It seems that this is unrelated to the change.

https://github.com/maplibre/maplibre-native/actions/runs/16457498317/job/46555453962

Looks OK to me (but I do not have time to test it). Will backport it then later also to the OpenGL2 branch for now.

This is maybe more a question for @louwers as you have a better overview: I guess in worst case now we load too much data? Probably I'm paranoid, but this does not sound ideal for mobile devices?

What do you mean?

I think we abort if one zooms or pans while loading to avoid unnecessary data transfer. This MR now unconditionally disables that. I guess on desktops it's fine, but for mobile devices on data every byte saved usually matters.

I wonder if the requests that are upcomming not already removed from the list. I would agree that the current live transfer will be finished in this scenario.

https://github.com/maplibre/maplibre-native/pull/3645/files#diff-0f6edf95426d1644f0d13239a71353940518944ac0b60078d3da88f71d0c0666R59

I was looking into this a bit more. Do you have a server where this can be reproduced, as I can not do it? Also supposedly Qt should handle HTTP/2 aborts just fine.

I was looking into this a bit more. Do you have a server where this can be reproduced, as I can not do it? Also supposedly Qt should handle HTTP/2 aborts just fine.

Absolutely, this is mbtileserver plus haproxy. https://zonekaart.nl/style.json

OK, I can now reproduce this issue both on Linux and macOS using the MapLibre test style. The issue is this seems to break a unit test. I suspect there's some issue with threading and HTTP/2.

There are several fixes that will land in Qt 6.9.2 (in a few days): https://bugreports.qt.io/browse/QTBUG-132124?jql=project%20%3D%20QTBUG%20AND%20text%20~%20%22qt.network.http2.connection%22%20ORDER%20BY%20created%20DESC

Let's test there if the situation improves.

Would you agree even if 6.9.2 would resolve the issue, it should still be mitigated for any version before?

Would you agree even if 6.9.2 would resolve the issue, it should still be mitigated for any version before?

In principle yes, but the fix should not break timeouts handling. Also everyone reports the issue only for Qt 6.9 when HTTP/2 is used by default (if I understand correctly it was opt-in before).